An ever-increasing number of e-commerce providers or e-businesses rely on application server technology as the lifeblood of their business. Application servers form a proven foundation for developing and supporting e-commerce applications, providing the presentation, business and information-access logic, security and management services, and the underlying infrastructure required for running highly scalable and mission-critical software applications. The increasing demand of today's modern businesses require support for a new breed of Web and wireless applications, helping to meet the needs of increasingly sophisticated customers.
One such application server, WebLogic Server, from BEA Systems, Inc. San Jose, Calif., is based on an implementation of the Java 2 Enterprise Edition (J2EE) specification. WebLogic Server is used as the backbone for many of today's most sophisticated e-business applications, and plays an integral role in a tightly integrated, comprehensive infrastructure that delivers commerce, personalization, campaign management, enterprise integration, workflow management, and business-to-business collaboration. WebLogic Server manages all of the underlying complexities of a business' e-commerce applications, allows the organization to focus instead on delivering new and innovative products and services.
A typical application server, including WebLogic Server, supports a variety of clients, including Web browsers, and wireless devices. On the server side, WebLogic Server supports a variety of operating systems. On the back-end, WebLogic Server integrates with relational databases, messages queues, and legacy systems. WebLogic Server also provides support for features such as Servlets, Java Server Pages (JSPs), Enterprise JavaBeans (EJBs), and Java Messaging Service (JMS), to provide access to standard network protocols, database, and messaging systems. When developing applications, developers can create, assemble, and deploy components that use these services. To allow communication between each of these entities, application servers typically allow applications to pass messages to each other. Messages are events that contain information needed to coordinate communication between different applications. A message thus provides a level of abstraction, allowing the software developer to separate out the details about the destination system from the application, and concentrate on developing the application code itself.
The EJB architecture used by such application servers encourages portability and reuse of application code. In accordance with the industry-standard EJB specification, enterprise bean instances are created and managed at application run time by an EJB container. An EJB container is a container that provides life cycle management, security deployment and run time services to EJB components. The EJB container may provide specific services. When an enterprise bean uses only those standard services defined in the EJB specification, the bean can be deployed within any compliant EJB container. However, application vendor's specialized containers can be used to provide additional services beyond those defined by the specification.
Besides its actual implementation, the behavior of the EJB can also be defined during deployment. EJB's are deployed using a deployment descriptor, typically a computer-readable file or group of files that specifies deployment assembly information and settings. By modifying the entries within this deployment descriptor, the behavior of the EJB can be customized. This flexibility makes it easy to change behavior in an EJB within an application at a later point in time without having to make any changes to the application source code.
The EJB itself must include a minimum of three classes, including:                A remote interface, which exposes the methods of the bean to the outside world,        A bean class, which implements methods specified by the remote interface, and,        A home interface which specifies how a new bean should be created, deleted or managed.        
As mentioned briefly above, EJB deployment descriptors are used to contain structural application assembly information for a particular EJB. A developer or administrator specifies this information by specifying or entering values for the deployment descriptors within each of the deployment descriptor files. Typically this can be done using either a text editor, or a development console, or integrated development environment. The EJB specification mandates at least an EJB-JAR.xml file for entity bean use in defining the deployment. Other application servers may include additional deployment descriptor files, according to their particular needs for flexibility. For example, the WebLogic application server also includes a Weblogic-EJB-JAR.xml file and a Weblogic-CMP-RDBMS-JAR.xml file for use in run time deployment. Each of these xml files are packaged together with EJB and other classes to form a deployable EJB component, usually a JAR file or an EAR file. The content and arrangement of elements within each of the component xml files must conform to any document type definition (DTD) for each file used. The effect is to verify or ensure the consistency of the xml file used for deployment description.
During deployment of an EJB, the following steps are followed:                The standard deployment descriptor and optionally any extended deployment descriptors are created, perhaps by a software developer or administrator, or more typically by an EJB deployment developer. When the application is to be provided by a third party, the third party or bean provider is responsible for creating these files.        The administrator is then responsible for using these files to create deployable EJB-JAR files.        The EJB deployer is started, and an EJB jar file loaded. Using the EJB deployer an administrator or EJB deployer can change setting within the deployment descriptors.        When satisfied with the deployment description, the EJB-JAR file is then deployed. This deployment generates the container classes and adds the container classes to the EJB-JAR file.        The final step in the deployment process is to copy the EJB-JAR file to the target server.        
The EJB deployment process described above is just one example of many different deployment processes that can be used with application servers. The EJB specification does not require or mandate any particular deployment process, and hence many different deployment mechanisms are used by the variety of application server vendors within this industry. The key points that are common to most deployment processes is to create the deployment descriptor file and to use this in creating the EJB container. Other details regarding the deployment are usually left to the discretion of the application service vendor.
Types of Enterprise Java Beans
In the world of EJB objects, there are three primary types of enterprise java beans: messenger beans, session beans and entity beans. Message beans (or message-driven beans) are generated to process Java Messaging Service (“JMS”) messages. Session beans, which are usually not accessible by the client, are used to perform specific tasks by the clients where only the results of that bean is returned to the client. Entity beans include a unique identifier, known as a primary key. The client does not have direct access to the primary key, but is given an interface in which to access the entity bean. Entity beans are thus commonly used for representing persistent data, providing concurrent access to that data by multiple clients, or for example, representing a single object or row of data retrieved from a database or data repository. If the state of the business object needs to be stored in persistent storage then it is typically modeled as an entity bean. Similarly when the data should be shared among multiple clients either simultaneously or within a short period of time from each other then the data object should be modeled as an entity bean. For this reason entity beans are very useful in accessing database information, particularly when loading an individual or logical record within that database. In the context of this invention, an EJB may be, for example, an entire record identifying an employees name, address and telephone number.
One common problem application servers such as described above, and with the traditional mechanism by which EJB's are provided to the client, is that little consideration is given to caching the EJB's in an efficient manner that provides for optimal speed and minimal interaction with a database or data repository. In typical e-commerce applications that retrieve data from databases or data repositories, when a client request is processed, an entity bean is created for each item or object of data retrieved from the database. The retrieved information may be cached, so that the same client (or a different client needing access to the same data) may quickly and easily retrieve it from cache. While this method results in time savings when re-reading previously read data, it provides no performance benefit when a client tries to read related, but un-queried data on subsequent attempts. Whether the subsequent data pertains to related or unrelated data, the process of determining an appropriate entity bean and retrieving it into the cache is the same. Mechanisms that can speed up this process can lead to substantial performance increases, and are highly desirable in today's e-commerce environment.